聽說，這個書名引發了一些爭議。老闆角色的人看這本書都認為RD團隊讀完後就是吃了大補丸，以後做專案只需要一半的時間就好，所以都樂於引進SCRUM。（燦笑）

如果不要使用這麼聳動的書名，中庸一點的，應該是使用「事半功倍」這句成語來說明Scurm，才是比較精準的吧。

但是，不管在原本的書名中，「用一半的時間」，與成語的「事半」，還是會讓人有偷雞的想像覺得好像不用付出什麼力氣，就能得到兩倍的效果。但事實上，付出多少，就獲得多少的等價概念，基本上還是存在於大部分的情況，鮮少有例外。

因為我的教會正在建新堂中(募款中，願意奉獻者請私訊)，我大概能理解建築業應該是最計較時程的行業，因為他們的工作階段非常多，不同類型的工班有不同的進場時間，可能還要顧慮現場施工環境、設計圖仍可能有錯誤需要現場修正等等細節。而建築合約中也可能有提早完工的獎勵條款，或者時程延遲的懲罰條款等，因此一個複雜建築工程專案有著不同的拉力與推力冥冥之中拉扯著。

但建築類的專案，前期花費大量的溝通時間與精力與發案方進行溝通與細節確認，沒有定案之前你很難有可以偷跑的工作先進行。因此這類的專案就是標準的瀑布流的專案進行方式。工作就是一環卡一環，前置作業沒有完成前，下一個步驟無法進行。所以這類的工作被詬病的就是通常時程會拉很長，需求方發想開始到最後完成都是很長的期限，但是這樣的優點基本上只要前一手的工作做的確實沒有問題，下一手工作範圍很明確，產出也很清楚。

只是，在軟體業，或者新創業圈，時間就是金錢，一個概念的發想，就是要早點丟到市場上運作，才會知道是否有效，或者如何修改，因此不可能讓專案人員paper work到天昏地老後才開始動工。

所以相對於建築類的專案，軟體類的專案是最有可能可以多個子專案多箭齊發同時進行，讓一組序列的工作可以透過多執行緒的概念同時併發執行出去，達到真正縮等待時間的期望。

但是，寫過多執行緒的人應該知道，執行緒的管理才是最頭痛的事情!!!更何況，如果發出去的多執行緒彼此還需要溝通，這個管理機制的設計過程才是真正會讓人想死的!!

所以想要「事半」「功倍」，我認為不是不行，而是你需要花更多的力氣，做更多的事前準備工作，才能讓不明就裡的人覺得你只用「別人一半的時間」做出「別人好幾倍的事」。

首先，你要知道什麼是「對的事情」，要先做；
再來，因為你不是自己做，所以要讓大家知道如何「把事情做對」；
再來，因為不是一個人/團隊做，所以要讓多人/團隊之間學會溝通；
再來，因為市場變化快，要不斷的與需求方溝通確認「對的事情」持續是對的；
再來，團隊一定會犯錯，所以要給團隊不斷地做心理建設與良性溝通；
再來，產品上線後要面對時間與人力被新需求與線上問題給瓜分；
再來........

想敏捷，卻沒有決心自己要比其他人承擔更多的SM或者專案管理人，也不要把敏捷的責任推給工程師了。